Debugging a network switch by replaying configuration

ABSTRACT

A network switch may be debugged by creating a virtual instance of the switch. Configuration data of the network switch may be retrieved, the configuration data including lists of the rules and groups configured on the switch. An isolated virtual environment may be created, and a virtual switch may be provisioned on the isolated virtual environment. The virtual switch may be configured with the configuration data of the network switch, including the rules and groups configured thereon. Diagnostic data corresponding to the switch may be obtained from the virtual switch.

TECHNICAL FIELD

Aspects of the present disclosure relate to network switches, and moreparticularly, to the debugging of network switches.

BACKGROUND

Network switches are devices that connect different devices together ona network by using packet switching to receive, process, and forwarddata to the destination device. An OpenFlow™ switch is a programmablenetwork switch that forwards packets in a software-defined networking(SDN) environment. OpenFlow™ switches may be implemented as a softwareprogram or hardware device and are either based on the OpenFlow™switching protocol or compatible with it. The OpenFlow™ SwitchingProtocol is defined by the OpenFlow™ Switch Consortium in the OpenFlow™Switch Specification, and is intended as a way for researchers to runexperimental protocols in their networks.

BRIEF DESCRIPTION OF THE DRAWINGS

The described embodiments and the advantages thereof may best beunderstood by reference to the following description taken inconjunction with the accompanying drawings. These drawings in no waylimit any changes in form and detail that may be made to the describedembodiments by one skilled in the art without departing from the spiritand scope of the described embodiments.

FIG. 1 is a block diagram that illustrates an example data center, inaccordance with some embodiments of the present disclosure.

FIG. 2A is a block diagram that illustrates an example virtualenvironment executing within a computing device, in accordance with someembodiments of the present disclosure.

FIG. 2B is a block diagram that illustrates an example virtualenvironment executing within a computing device, in accordance with someembodiments of the present disclosure.

FIG. 3 is a flow diagram of a method of debugging a network switch, inaccordance with some embodiments of the present disclosure.

FIG. 4 is a flow diagram of a method of configuring a virtual switch, inaccordance with some embodiments of the present disclosure.

FIG. 5 is a block diagram of an example computing device that mayperform one or more of the operations described herein, in accordancewith some embodiments of the present disclosure.

FIG. 6 is a block diagram of an example apparatus that may perform oneor more of the operations described herein, in accordance with someembodiments of the present disclosure.

DETAILED DESCRIPTION

OpenFlow™ network switches may be configured with rules, also known asflows, and groups. Rules may be considered as criteria that packets arematched against, such as header values that can be used to match againstpacket headers. Each rule may be associated with one or more actions toapply to packets that match with the rule. For example, if a packetmatches with a rule, an associated action might be to forward the packetto a specified port. Actions may be collected in groups, and groups mayin turn also be associated with a particular rule. In addition, groupsof actions may have dependencies on one another. For example, before afirst group of actions can be applied to a packet that has matched arule, a second group of actions may need to be applied to that rule.Thus, the first group depends from the second group.

As with many network functions, switching devices can be virtualized,and included as part of a software defined network (SDN). Networkfunctions virtualization (NFV) implements network functions as virtualmachines (VMs) on a general-purpose, cloud-based infrastructure, ratherthan as dedicated physical hardware. By using a single infrastructurefor all the virtual network functions (VNFs) in a SDN, organizations candrastically reduce capital expenses (CapEx) and operational expenses(OpEx) through increased system utilization and streamlinedadministration.

As discussed above, OpenFlow™ switches can be programmed with rules andgroups (of actions) to perform packet routing and other essentialfunctions. Many OpenFlow™ switches provide tools for debugging them. Forexample, OpenFlow™ switches may provide diagnostic data indicating,among other statistics, the number of times a rule matched with apacket. In addition, OpenFlow™ switches may provide rule evaluationsimulations using mock packets injected into the switch. Despite this,it is generally easier to debug a live running system than to determineproblems based on logs and/or diagnostic data alone. In addition, atypical cloud usage of OpenFlow™ switches may include large numbers ofswitches containing thousands of rules, where each rule may be expressedas a network level field specification with non-standard extensionfields, which may make them difficult to read. In such scenarios,debugging an OpenFlow™ switch can be difficult and complex. Further, inmany scenarios, the actual cloud environment is usually not accessibleto a person debugging a switch.

The present disclosure addresses the above-noted and other deficienciesby using a processing device to create a virtual instance of an existingOpenFlow™ switch, the virtual instance being configured with the rulesand groups of the existing OpenFlow™ switch. The processing device mayobtain configuration data from the OpenFlow™ switch using standardOpenFlow™ protocol constructs. The configuration data may include a listof all ports attached to the OpenFlow™ switch, a media access control(MAC) address and an interne protocol (IP) address for each portattached to the OpenFlow™ switch, a list indicating one or more groupsconfigured on the OpenFlow™ switch, and a list of the rules configuredon the OpenFlow™ switch. The processing device may then create anisolated virtual environment that is not connected to any other networkdevice or component, virtual or otherwise. The isolated virtualenvironment may be a virtual machine (VM) or a container. The processingdevice may provision a virtual switch on the isolated virtualenvironment and configure the virtual switch with the configurationdata, including the rules and groups configured on the OpenFlow™ switch.This results in a fully functional virtual instance of the existingOpenFlow™ switch which may be debugged in real time using virtual switchdiagnostic tools and OpenFlow™ diagnostic tools. For example, theprocessing device may inject packet traffic into the virtual ports ofthe virtual switch and observe rule statistics (i.e. the number of timesa packet matched with a rule). Although discussed in terms of anOpenFlow™ switch, embodiments of the present disclosure may be appliedto the debugging of any rule/group-based switch.

FIG. 1 is a block diagram that illustrates an example data center 100.As illustrated in FIG. 1, the data center 100 includes a plurality ofcomputing devices 110 and 120, a data store 130, and a network 140. Thecomputing devices 110, the computing device 120, and the data store 130may be coupled to each other (e.g., may be operatively coupled,communicatively coupled, may communicate data/messages with each other)via network 140. Network 140 may be a public network (e.g., theinternet), a private network (e.g., a local area network (LAN) or widearea network (WAN)), or a combination thereof. In one embodiment,network 140 may include a wired or a wireless infrastructure, which maybe provided by one or more wireless communications systems, such as awireless fidelity (WiFi) hotspot connected with the network 140 and/or awireless carrier system that can be implemented using various dataprocessing equipment, communication towers (e.g. cell towers), etc. Thenetwork 140 may carry communications (e.g., data, message, packets,frames, etc.) between computing devices 110 and 120, and the data store130. The data store 130 may be a persistent storage that is capable ofstoring data. A persistent storage may be a local storage unit or aremote storage unit. Persistent storage may be a magnetic storage unit,optical storage unit, solid state storage unit, electronic storage units(main memory), or similar storage unit. Persistent storage may also be amonolithic/single device or a distributed set of devices.

Each computing device may include hardware such as processing devices(e.g., processors, central processing units (CPUs), memory (e.g., randomaccess memory (RAM), storage devices (e.g., hard-disk drive (HDD),solid-state drive (SSD), etc.), and other hardware devices (e.g., soundcard, video card, etc.). The computing devices 110 may comprise anysuitable type of computing device or machine that has a programmableprocessor including, for example, server computers, desktop computers,laptop computers, tablet computers, smartphones, set-top boxes, etc. Insome examples, the computing devices 110 and 120 may comprise a singlemachine or may include multiple interconnected machines (e.g., multipleservers configured in a cluster). The computing devices 110 and 120 maybe implemented by a common entity/organization or may be implemented bydifferent entities/organizations. For example, a first computing device110 may be operated by a first company/corporation and a secondcomputing device 110 may be operated by a second company/corporation.Each computing device 110 and 120 may execute or include an operatingsystem (OS), as discussed in more detail below. The OS of a computingdevice 110 and 120 may manage the execution of other components (e.g.,software, applications, etc.) and/or may manage access to the hardware(e.g., processors, memory, storage devices etc.) of the computingdevice.

As illustrated in FIG. 1, each computing device 110 includes a virtualenvironment 113. In some embodiments, a virtual environment 113 may be avirtual machine (VM) that may execute on a hypervisor (shown in FIG. 2A)which executes on top of the OS for a computing device, as discussed inmore detail below. The hypervisor may manage system resources (includingaccess to hardware devices, such as processors, memories, storagedevices), as discussed in more detail below. The hypervisor may alsoemulate the hardware (or other physical resources) which may be used bythe VMs to execute software/applications, as discussed in more detailbelow. In another embodiment, a virtual environment 113 may be acontainer that may execute on a container engine which executes on topof the OS for a computing device, as discussed in more detail below. Thecontainer engine may allow different containers to share the OS of acomputing device (e.g., the OS kernel, binaries, libraries, etc.), asdiscussed in more detail below. The container engine may also performother functions, as discussed in more detail below. The virtualenvironment 113 may be isolated, in that it is not connected to anyother device or component of data center 100, whether virtual orotherwise.

In some embodiments, a network virtualization platform (illustrated inFIGS. 2A and 2B), such as RedHat™ OpenStack™, may also execute on the OSof the computing device. The network virtualization platform may use aconsistent set of application programming interfaces (APIs) to abstractthose virtual resources provided by the hypervisor one step further intodiscrete pools that may be used to configure and deploy a virtualenvironments (e.g., virtual environment 113) and virtual networkfunctions (VNFs) (e.g., VNF 115) that administrators and users mayinteract with directly. The network virtualization platform may includea deployment controller to handle creation of virtual environments(including VMs and containers) as well as provisioning of such virtualenvironments with VNFs. The deployment controller may also function tomanage the operations of the VNFs. For example, the networkvirtualization platform may utilize the deployment controller to createvirtual switches (and a virtual environment for the switch to run on) aswell as manage the operations of the virtual switch (e.g.,configuring/modifying rules and groups, managing connections with otherVNFs and handling diagnostic tasks).

As further illustrated in FIG. 1, each virtual environment 113 includesa VNF 115. For example, VNF 115 may execute in a VM or a container.Although one VNF 115 is illustrated in a respective virtual environment113, a virtual environment 113 may include multiple VNFs 115 in otherembodiments. In addition, each computing device 110 in the network 100may use the same type or different types of virtual environments 113.For example, each virtual environment 113 may be a VM. In anotherexample, each virtual environment 113 may be a container. In a furtherexample, some of the virtual environments 113 may be VMs and othervirtual environments 113 may be containers. VNFs 115 may be deployed andmanaged by a deployment controller (not illustrated in the figures)executing as part of a network virtualization platform.

Each virtual environment 113 may include a runtime environment (notillustrated in the figures). A runtime environment may refer to aconfiguration of hardware and/or software that supports the execution ofdifferent types of applications which may be written in differentprogramming languages. Different runtime environments may allow/usedifferent programming languages and/or different versions of programminglanguages. The runtime environments for the virtual environments 113 maybe different. In one embodiment, a first runtime environment may use adifferent programing language than a second runtime environment. Forexample, a first runtime environment may use JavaScript and a secondruntime environment may use Python. In another embodiment, a firstruntime environment may use a different version of a programminglanguage than a second runtime environment. For example, a first runtimeenvironment may use JavaScript version 5.1 and a second runtimeenvironment may use JavaScript version 6. In a further embodiment, afirst runtime environment may use different libraries and/or differentversion of libraries than a second runtime environment. For example, afirst runtime environment may use AngularJS (e.g., a JavaScript basedlibrary) and a second runtime environment may use React (a differentJavaScript based library). In another example, a first runtimeenvironment may use AngularJS version 1.5 and a second runtimeenvironment may use AngularJS version 4.

The computing device 120 includes a virtual environment 123 (e.g., a VM,a container, etc.), upon which an OpenFlow™ switch 127 may run. Theoperations of OpenFlow™ switch 127 may be managed by a deploymentcontroller (not illustrated in the figures) that executes as part of anetwork virtualization platform as discussed above. In some embodiments,the deployment controller may monitor and record configuration data suchas a list of all ports attached to the OpenFlow™ switch 127, a mediaaccess control (MAC) address and an internet protocol (IP) address foreach port attached to the OpenFlow™ switch 127, a list indicating one ormore groups configured on the OpenFlow™ switch 127, and a list of therules configured on the OpenFlow™ switch 127. The lists may beretrievable from the OpenFlow™ switch 127 using standard OpenFlow™protocol constructs. However, retrieval of MAC and IP addresses maydepend on the nature of the runtime environment of virtual environment123. For example, if the runtime environment is an OpenStack™ runtimeenvironment, MAC and IP addresses may be retrievable in the form of datastructures corresponding to virtual ports. Although illustrated as avirtual component running on a separate computing device in FIG. 1,OpenFlow™ switch 127 may also be implemented on a virtual environment113 running on any computing device 110, or alternatively may beimplemented in hardware separate from any computing device 110.

As discussed above, by allowing the components of the data center 100 tooperate within different virtual environments, each component of thenetwork may be implemented using a different programminglanguage/version of a programming language and may execute within adifferent runtime environment in a virtual environment. This allowsdifferent developers to use their preferred programming language whendeveloping components of the network 100 and may also allow networks tobe developed more easily among larger teams of developers (since eachteam of developers may develop their respective components withoutcoordinating the programming language/version with the other teams).This further allows the networks to be updated/scaled up more easilysince new components may be added more easily.

FIG. 2A is a block diagram that illustrates an example virtualenvironment executing within a computing device 110, in accordance withsome embodiments of the present disclosure. The computing device 110 mayinclude hardware (e.g., processing devices, memory, storage devices,other devices, etc.) and a host OS 211. As discussed above, one type ofa virtual environment may be a VM 213 executing on a computing device110. In one embodiment, the VM 213 may be a software implementation of amachine (e.g., a software implementation of a computing device) thatincludes its own operating system (referred to as guest OS 214) andexecutes application programs, applications, and software such as VNFs.VM 213 may be, for example, a hardware emulation, a full virtualization,a para-virtualization, and an operating system-level virtualization VM.

Computing device 110 may include a hypervisor 212A, which may also beknown as a virtual machine monitor (VMM). In the example shown,hypervisor 212A may be a component of a host operating system 211. Inanother example, hypervisor 212A may run on top of a host operatingsystem 211, or may run directly on host hardware without the use of ahost operating system 211. Hypervisor 212A may manage system resources,including access to physical processing devices (e.g., processors, CPUs,etc.), physical memory (e.g., RAM), storage device (e.g., HDDs, SSDs),and/or other devices (e.g., sound cards, video cards, etc.). Thehypervisor 212A, though typically implemented in software, may emulateand export a bare machine interface to higher level software in the formof virtual processors and guest memory. Higher level software maycomprise a standard or real-time operating system (OS), may be a highlystripped down operating environment with limited operating systemfunctionality, and/or may not include traditional OS facilities, etc.For example, higher level software may be a network virtualizationplatform 212B such as RedHat™ OpenStack™, as discussed above. Hypervisor212A may present other software (i.e., “guest” software) the abstractionof one or more virtual machines (VMs) that provide the same or differentabstractions to various guest software (e.g., guest operating system,guest applications).

VM 213 may execute guest software that uses an underlying emulation ofthe physical resources (e.g., virtual processors and guest memory). Asillustrated in FIG. 2A, VM 213 may execute a VNF 115 (e.g., acomponent/part of a larger network), such as a virtual switch, within aruntime environment (not shown in the figures). Both the VM 213 and theVNF115 may be configured and deployed by a network virtualizationplatform 212B executing atop the host OS 211, as discussed above. Thenetwork virtualization platform 212B, via the computing device 110 mayprovide administrators and users with the capability to virtualize avariety of network functions.

FIG. 2B is a block diagram that illustrates an example virtualenvironment executing within a computing device, in accordance with someembodiments of the present disclosure. The computing device 110 mayinclude hardware (e.g., processing devices, memory, storage devices,other devices, etc.) and a host OS 221. As discussed above, one type ofa virtual environment may be a container 223 executing on a computingdevice 110. In one embodiment, the container 223 may be an isolated setof resources allocated to executing an application, software, and/orprocess independent from other applications, software, and/or processes.The host OS 221 may use namespaces to isolate the resources of thecontainers from each other. In another embodiment, the container 223 maybe a virtualized object similar to virtual machines. However, container223 may not implement separate guest OS (like VM 213 illustrated in FIG.2A). The container 223 may share the kernel, libraries, and binaries ofthe host OS 221with other containers that are executing on the computingdevice 110. Although FIG. 2B illustrates one container 223, thecomputing device 110 may include multiple containers in otherembodiments. Each container may have one or more respective,filesystems, memories, devices, network ports, etc., for accessing thephysical resources of the computing device 110.

In one embodiment, the container engine 222A may allow differentcontainers to share the host OS 221 (e.g., the OS kernel, binaries,libraries, etc.) of the computing device 110. For example, the containerengine 222A may multiplex the binaries and/or libraries of the host OS221 between multiple containers. The container engine 222A may alsofacilitate interactions between the container and the resources of thecomputing device 110. For example, the container engine 222A may managerequests from container 223 to access a memory (e.g., a RAM) of thecomputing device 110. In another example, the container engine 222A maymanage requests from the container 223 to access certainlibraries/binaries of the host OS 223. In other embodiments, thecontainer engine 222A may also be used to create, remove, and managecontainers. In one embodiment, the container engine 222A may be acomponent of a host operating system 221. In another embodiment,container engine 222 may run on top of a host operating system 221, ormay run directly on host hardware without the use of a host operatingsystem 221. In yet other embodiments, container engine 222A may be acomponent of network virtualization platform 222B (as illustrated inFIG. 2B), that runs on host OS 211.

As illustrated in FIG. 2B, VNF s15 (e.g., a component/part of a largernetwork) may execute within the container 223. For example, the VNF 115may execute within a runtime environment (not shown in the figures) ofthe container 223. Both the container 223 and the VNF 215 may be createdby a network virtualization platform 222B. The network virtualizationplatform 222B may run on the host OS 211 and in some embodiments thecontainer engine 222A may b a component of the network virtualizationplatform 222B. The network virtualization platform 222B, via thecomputing device 110 may provide administrators and users with thecapability to configure and deploy a variety of network functions withincontainers.

FIG. 3 is a flow diagram of a method 300 of debugging an OpenFlow™switch, in accordance with some embodiments. Method 300 may be performedby processing logic that may comprise hardware (e.g., circuitry,dedicated logic, programmable logic, a processor, a processing device, acentral processing unit (CPU), a system-on-chip (SoC), etc.), software(e.g., instructions running/executing on a processing device), firmware(e.g., microcode), or a combination thereof. In some embodiments, themethod 300 may be performed by a computing device (e.g., computingdevice 110 illustrated in FIG. 1).

The method 300 begins at block 305, where the computing device 110 mayobtain configuration data from an existing OpenFlow™ switch (e.g.,OpenFlow™ switch 127 illustrated in FIG. 1). As discussed above,computing device 110 may utilize a network virtualization platform suchas RedHat™ OpenStack™ which may include a deployment controller toconfigure and deploy virtual environments as well as instances of VNFsatop those virtual environments. The deployment controller may alsomanage the operations of the VNFs. Computing device 110 may utilizestandard OpenFlow™ protocol constructs in order to obtain theconfiguration data from the OpenFlow™ switch. However, retrieval of MACand IP addresses may depend on the nature of the runtime environment ofvirtual environment 123. For example, if the runtime environment is anOpenStack™ runtime environment, MAC and IP addresses may be retrievablein the form of data structures corresponding to virtual ports. Theconfiguration data may include a list of all ports attached to theOpenFlow™ switch, a media access control (MAC) address and an interneprotocol (IP) address for each port attached to the OpenFlow™ switch, alist indicating one or more groups configured on the OpenFlow™ switch,and a list of the rules configured on the OpenFlow™ switch. In someembodiments, the configuration data may include a packet capture thatincludes packet traffic that was injected into a port of the OpenFlow™switch. At block 310, computing device 110 may create an isolatedvirtual environment (e.g., virtual environment 113), that acts as astand-alone virtual environment. Computing device 110 may ensure thatthe isolated virtual environment has no connection to any other deviceor component of data center 100, including any other virtual environment113 or any other computing device 110, and has no connection to thenetwork 140. The isolated virtual environment may have access to thehardware resources needed to support a virtual switch instance and berestricted from any other resources. Computing device 110 may deploy theisolated virtual environment as a VM, or as a container, as discussed infurther detail herein. At block 315, computing device 110 maysubsequently provision a virtual switch on the isolated virtualenvironment and at block 320, may configure the virtual switch using theconfiguration data.

FIG. 4 is a flow diagram of a method 400 of configuring a virtual switchwith configuration data from an OpenFlow™ switch, in accordance withsome embodiments. Method 400 may be performed by processing logic thatmay comprise hardware (e.g., circuitry, dedicated logic, programmablelogic, a processor, a processing device, a central processing unit(CPU), a system-on-chip (SoC), etc.), software (e.g., instructionsrunning/executing on a processing device), firmware (e.g., microcode),or a combination thereof. In some embodiments, the method 400 may beperformed by a computing device (e.g., computing device 110 illustratedin FIG. 1).

The method 400 begins at block 405, where for each port attached to theOpenFlow™ switch, the computing device 110 may create a correspondingvirtual port and attach it to the virtual switch. Computing device 110may create each virtual port as a TAP device, which may simulate a linklayer device operating with layer two packets (e.g., Ethernet frames),thereby creating a network bridge. Computing device 110 may attach eachsuch TAP device to the virtual switch. Computing device 110 may thenconfigure each virtual port with the IP and MAC address of thecorresponding OpenFlow™ switch port. At block 410, computing device 110may configure the virtual switch with the groups configured on theOpenFlow™ switch. However, certain groups may depend on each other, andthe list of groups obtained from the OpenFlow™ switch may not be orderedin view of these dependencies. If a first group depends on a second andthird group, then the first group cannot be configured on the virtualswitch until the second and third groups are configured. To overcomethis, computing device 110 may iteratively attempt to configure eachgroup in the list, until a group is successfully configured on thevirtual switch. At block 415, upon successful configuration of a group,that group is removed from the list, and computing device 110 determineswhether all groups have been successfully configured. If not, computingdevice 110 repeats the process (iteratively attempting to configure eachgroup) with the remaining groups until another group is successfullyconfigured on the virtual switch. Computing device 110 may continue inthis fashion until all the groups have been successfully configured. Atblock 420, computing device 110 may configure the virtual switch witheach of the rules from the list of the rules configured on the OpenFlow™switch. Thus, the virtual switch is now a fully functional networkvirtualization of the OpenFlow™ switch.

Upon realizing the fully functional network virtualization of theOpenFlow™ switch, a user may (via computing device 110) obtaindiagnostic data from the virtual switch. More specifically, the networkvirtualization platform may provide an interface to a user via thecomputing device 110 so that the user may obtain diagnostic data fromthe virtual switch. Diagnostic data may be obtained using standardnetwork diagnostic tools and OpenFlow™ diagnostic tools. For example, auser may obtain rule matching statistics, which indicate the number oftimes a packet matched with one or more particular rules after mockpacket traffic has been injected into the virtual switch. In addition, auser may utilize rule evaluation simulators, such as the trace functiondefined by the OpenFlow™ protocol, which may inject mock packets intothe virtual switch to see which rules they match with. Users can alsoattempt to modify certain rules and see how packet traffic is affected.Further, a user can also utilize standard network diagnostic tools suchas tcpdump and ping etc. In some embodiments, the configuration dataincludes a packet capture that includes packet traffic injected into theOpenFlow™ switch, and the corresponding ports the packet traffic wasinjected into. Thus, a user may utilize the packet capture to re-injectthe packet traffic into the corresponding virtual ports of the virtualswitch so as to allow for observation of which rules the packets matchwith and recording of matching statistics etc. In this way, any bugs orissues affecting the OpenFlow™ switch can be recreated on the virtualswitch.

FIG. 5 is a block diagram of an example computing device 500 that mayperform one or more of the operations described herein, in accordancewith some embodiments. Computing device 500 may be connected to othercomputing devices in a LAN, an intranet, an extranet, and/or theInternet. The computing device may operate in the capacity of a servermachine in client-server network environment or in the capacity of aclient in a peer-to-peer network environment. The computing device maybe provided by a personal computer (PC), a set-top box (STB), a server,a network router, switch or bridge, or any machine capable of executinga set of instructions (sequential or otherwise) that specify actions tobe taken by that machine. Further, while only a single computing deviceis illustrated, the term “computing device” shall also be taken toinclude any collection of computing devices that individually or jointlyexecute a set (or multiple sets) of instructions to perform the methodsdiscussed herein.

The example computing device 500 may include a processing device (e.g.,a general purpose processor, a PLD, etc.) 502, a main memory 504 (e.g.,synchronous dynamic random access memory (DRAM), read-only memory(ROM)), a static memory 506 (e.g., flash memory and a data storagedevice 518), which may communicate with each other via a bus 530.

Processing device 502 may be provided by one or more general-purposeprocessing devices such as a microprocessor, central processing unit, orthe like. In an illustrative example, processing device 502 may comprisea complex instruction set computing (CISC) microprocessor, reducedinstruction set computing (RISC) microprocessor, very long instructionword (VLIW) microprocessor, or a processor implementing otherinstruction sets or processors implementing a combination of instructionsets. Processing device 502 may also comprise one or morespecial-purpose processing devices such as an application specificintegrated circuit (ASIC), a field programmable gate array (FPGA), adigital signal processor (DSP), network processor, or the like. Theprocessing device 502 may be configured to execute the operationsdescribed herein, in accordance with one or more aspects of the presentdisclosure, for performing the operations and steps discussed herein.

Computing device 500 may further include a network interface device 508which may communicate with a network 520. The computing device 500 alsomay include a video display unit 510 (e.g., a liquid crystal display(LCD) or a cathode ray tube (CRT)), an alphanumeric input device 512(e.g., a keyboard), a cursor control device 514 (e.g., a mouse) and anacoustic signal generation device 516 (e.g., a speaker). In oneembodiment, video display unit 510, alphanumeric input device 512, andcursor control device 514 may be combined into a single component ordevice (e.g., an LCD touch screen).

Data storage device 518 may include a computer-readable storage medium528 on which may be stored one or more sets of instructions, e.g.,instructions for carrying out the operations described herein, inaccordance with one or more aspects of the present disclosure.Instructions implementing module 526 may also reside, completely or atleast partially, within main memory 504 and/or within processing device502 during execution thereof by computing device 500, main memory 504and processing device 502 also constituting computer-readable media. Theinstructions may further be transmitted or received over a network 520via network interface device 508.

While computer-readable storage medium 528 is shown in an illustrativeexample to be a single medium, the term “computer-readable storagemedium” should be taken to include a single medium or multiple media(e.g., a centralized or distributed database and/or associated cachesand servers) that store the one or more sets of instructions. The term“computer-readable storage medium” shall also be taken to include anymedium that is capable of storing, encoding or carrying a set ofinstructions for execution by the machine and that cause the machine toperform the methods described herein. The term “computer-readablestorage medium” shall accordingly be taken to include, but not belimited to, solid-state memories, optical media and magnetic media.

FIG. 6 is a block diagram of an example apparatus 610 that may performone or more of the operations described herein, in accordance with someembodiments. The apparatus 600 includes a memory 620 to store aconfiguration data retrieval component 620A and a virtual switchconfiguration component 620B. The apparatus 600 also includes aprocessing device 615 operatively coupled to the memory. The processingdevice 615 may execute the configuration data retrieval component 620Ato obtain, from an OpenFlow™ switch 637, a set of configuration dataincluding the rules and groups configured on the OpenFlow™ switch 637.The processing device 615 may then execute virtual switch configurationcomponent 620B to create an isolated virtual environment and provision avirtual switch instance on the isolated virtual environment. Theprocessing device 615 may configure the virtual switch using theconfiguration data retrieved from the OpenFlow™ switch 637. Theprocessing device 615 may then obtain diagnostic data from the virtualswitch.

Unless specifically stated otherwise, terms such as “receiving,”“routing,” “updating,” “providing,” or the like, refer to actions andprocesses performed or implemented by computing devices that manipulatesand transforms data represented as physical (electronic) quantitieswithin the computing device's registers and memories into other datasimilarly represented as physical quantities within the computing devicememories or registers or other such information storage, transmission ordisplay devices. Also, the terms “first,” “second,” “third,” “fourth,”etc., as used herein are meant as labels to distinguish among differentelements and may not necessarily have an ordinal meaning according totheir numerical designation.

Examples described herein also relate to an apparatus for performing theoperations described herein. This apparatus may be specially constructedfor the required purposes, or it may comprise a general purposecomputing device selectively programmed by a computer program stored inthe computing device. Such a computer program may be stored in acomputer-readable non-transitory storage medium.

The methods and illustrative examples described herein are notinherently related to any particular computer or other apparatus.Various general purpose systems may be used in accordance with theteachings described herein, or it may prove convenient to construct morespecialized apparatus to perform the required method steps. The requiredstructure for a variety of these systems will appear as set forth in thedescription above.

The above description is intended to be illustrative, and notrestrictive. Although the present disclosure has been described withreferences to specific illustrative examples, it will be recognized thatthe present disclosure is not limited to the examples described. Thescope of the disclosure should be determined with reference to thefollowing claims, along with the full scope of equivalents to which theclaims are entitled.

As used herein, the singular forms “a”, “an” and “the” are intended toinclude the plural forms as well, unless the context clearly indicatesotherwise. It will be further understood that the terms “comprises”,“comprising”, “includes”, and/or “including”, when used herein, specifythe presence of stated features, integers, steps, operations, elements,and/or components, but do not preclude the presence or addition of oneor more other features, integers, steps, operations, elements,components, and/or groups thereof. Therefore, the terminology usedherein is for the purpose of describing particular embodiments only andis not intended to be limiting.

It should also be noted that in some alternative implementations, thefunctions/acts noted may occur out of the order noted in the figures.For example, two figures shown in succession may in fact be executedsubstantially concurrently or may sometimes be executed in the reverseorder, depending upon the functionality/acts involved.

Although the method operations were described in a specific order, itshould be understood that other operations may be performed in betweendescribed operations, described operations may be adjusted so that theyoccur at slightly different times or the described operations may bedistributed in a system which allows the occurrence of the processingoperations at various intervals associated with the processing.

Various units, circuits, or other components may be described or claimedas “configured to” or “configurable to” perform a task or tasks. In suchcontexts, the phrase “configured to” or “configurable to” is used toconnote structure by indicating that the units/circuits/componentsinclude structure (e.g., circuitry) that performs the task or tasksduring operation. As such, the unit/circuit/component can be said to beconfigured to perform the task, or configurable to perform the task,even when the specified unit/circuit/component is not currentlyoperational (e.g., is not on). The units/circuits/components used withthe “configured to” or “configurable to” language include hardware—forexample, circuits, memory storing program instructions executable toimplement the operation, etc. Reciting that a unit/circuit/component is“configured to” perform one or more tasks, or is “configurable to”perform one or more tasks, is expressly intended not to invoke 35 U.S.C.112, sixth paragraph, for that unit/circuit/component. Additionally,“configured to” or “configurable to” can include generic structure(e.g., generic circuitry) that is manipulated by software and/orfirmware (e.g., an FPGA or a general-purpose processor executingsoftware) to operate in manner that is capable of performing the task(s)at issue. “Configured to” may also include adapting a manufacturingprocess (e.g., a semiconductor fabrication facility) to fabricatedevices (e.g., integrated circuits) that are adapted to implement orperform one or more tasks. “Configurable to” is expressly intended notto apply to blank media, an unprogrammed processor or unprogrammedgeneric computer, or an unprogrammed programmable logic device,programmable gate array, or other unprogrammed device, unlessaccompanied by programmed media that confers the ability to theunprogrammed device to be configured to perform the disclosedfunction(s).

The foregoing description, for the purpose of explanation, has beendescribed with reference to specific embodiments. However, theillustrative discussions above are not intended to be exhaustive or tolimit the embodiments to the precise forms disclosed. Many modificationsand variations are possible in view of the above teachings. Accordingly,the present embodiments are to be considered as illustrative and notrestrictive, and the invention is not to be limited to the details givenherein, but may be modified within the scope and equivalents of theappended claims.

What is claimed is:
 1. A method comprising: obtaining configuration datafrom a network switch, the configuration data comprising a listindicating one or more groups configured on the network switch, and alist of the rules configured on the network switch; generating anisolated virtual environment; provisioning a virtual switch on theisolated virtual environment; and configuring, by a processing device,the virtual switch in view of the configuration data.
 2. The method ofclaim 1, wherein the configuration data for the network switch furthercomprises: a list of one or more ports attached to the network switchand a media access control (MAC) address and an interne protocol (IP)address for each port attached to the network switch.
 3. The method ofclaim 2, wherein the network switch is an OpenFlow™ switch and each listis obtained using standard OpenFlow™ protocol constructs.
 4. The methodof claim 1, wherein the isolated virtual environment comprises acontainer.
 5. The method of claim 1, wherein configuring the virtualswitch further comprises: for each of the one or more ports attached tothe network switch, attaching a corresponding virtual port to thevirtual switch and configuring the corresponding virtual port with theport's MAC address and IP address; iteratively, until each of the one ormore groups configured on the network switch is successfully configuredon the virtual switch, attempting to configure each of the one or moregroups on the virtual switch until a group is successfully configured;and configuring the virtual switch with the rules configured on thenetwork switch.
 6. The method of claim 1, further comprising obtainingdiagnostic data from the virtual switch using network diagnostic toolsand OpenFlow™ diagnostic tools.
 7. The method of claim 6, whereinconfiguration data further comprises packet capture data and whereinobtaining diagnostic data further comprises injecting the packet capturedata into the virtual switch.
 8. A system comprising: a memory; aprocessing device operatively coupled to the memory, the processingdevice to: obtain configuration data from a network switch, theconfiguration data comprising a list indicating one or more groupsconfigured on the network switch, and a list of the rules configured onthe network switch; generate an isolated virtual environment; provisiona virtual switch on the isolated virtual environment; and configure, bythe processing device, the virtual switch based on the configurationdata.
 9. The system of claim 8, wherein the configuration data for thenetwork switch further comprises: a list of one or more ports attachedto the network switch, and a media access control (MAC) address and aninterne protocol (IP) address for each port attached to the networkswitch.
 10. The system of claim 9, wherein the network switch is anOpenFlow™ switch and wherein to obtain each list, the processing deviceis further to use standard OpenFlow™ protocol constructs.
 11. The systemof claim 8, wherein the isolated virtual environment is a container. 12.The system of claim 8, wherein to configure the virtual switch, theprocessing device is further to: for each of the one or more portsattached to the network switch, attach a corresponding virtual port tothe virtual switch and configure the corresponding virtual port with theport's MAC address and IP address; iteratively, until each of the one ormore groups configured on the network switch is successfully configuredon the virtual switch, attempt to configure each of the one or moregroups on the virtual switch until a group is successfully configured;and configure the virtual switch with the rules configured on thenetwork switch.
 13. The system of claim 8, wherein the processing deviceis further to obtain diagnostic data from the virtual switch usingnetwork diagnostic tools and OpenFlow™ diagnostic tools.
 14. The systemof claim 13, wherein the configuration data further comprises packetcapture data and wherein to obtain diagnostic data, the processingdevice is further to inject the packet capture data into the virtualswitch.
 15. A non-transitory computer-readable storage medium includinginstructions that, when executed by a processing device, cause theprocessing device to: obtain configuration data from a network switch,the configuration data comprising a list indicating one or more groupsconfigured on the network switch, and a list of the rules configured onthe network switch; generate an isolated virtual environment; provisiona virtual switch on the isolated virtual environment; and configure, bythe processing device, the virtual switch based on the configurationdata.
 16. The non-transitory computer-readable storage medium of claim15, wherein the configuration data for the network switch furthercomprises: a list of one or more ports attached to the network switchand a media access control (MAC) address and an interne protocol (IP)address for each port attached to the network switch.
 17. Thenon-transitory computer-readable storage medium of claim 16, wherein thenetwork switch is an OpenFlow™ switch and wherein to obtain each list,the processing device is further to use standard OpenFlow™ protocolconstructs.
 18. The non-transitory computer-readable storage medium ofclaim 15, wherein the isolated virtual environment is a container. 19.The non-transitory computer-readable storage medium of claim 15, whereinto configure the virtual switch, the processing device is further to:for each of the one or more ports attached to the network switch, attacha corresponding virtual port to the virtual switch and configuring thecorresponding virtual port with the port's MAC address and IP address;iteratively, until each of the one or more groups configured on thenetwork switch is successfully configured on the virtual switch, attemptto configure each of the one or more groups on the virtual switch untila group is successfully configured; configure the virtual switch withthe rules configured on the network switch.
 20. The non-transitorycomputer-readable storage medium of claim 15, wherein the processingdevice is further to obtain diagnostic data from the virtual switchusing network diagnostic tools and OpenFlow™ diagnostic tools.